fluent-plugin-datadogのバッチサイズとフラッシュ所要時間の関係
はじめに
fluent-plugin-datadog のパフォーマンスが気になったので実装の詳細を調査してベンチマークを実施しました。気になったことは以下の点です。
- 運用している環境でプラグインでのフラッシュ時間が長時間化する傾向にあり短縮したい
- バッファのチャンクサイズの調整でフラッシュ時間をチューニングする余地があるか知りたい
Datadog APIとプラグインを調査する
Datadog APIの仕様とプラグインの挙動を確認します。
APIの仕様
DatadogのSend logs APIには以下の制限があります。
ペイロードあたりの最大コンテンツサイズ (非圧縮) : 5MB
単一ログの最大サイズ : 1MB
アレイで複数のログを送信する場合の最大アレイサイズ : 1000 エントリ
プラグインの挙動
プラグインではfluentdのチャンクサイズにかかわらず上記の制限の範囲でイベントを複数のバッチに分割して送信しています。
https://github.com/DataDog/fluent-plugin-datadog/blob/master/lib/fluent/plugin/out_datadog.rb#L169
ベンチマーク
上記を踏まえて以下をベンチマークで確かめます。
- 1バッチ内のイベント数を変えた場合応答時間は変わるか? ⇒ イベント数によらず一定
- イベント数が同じ場合バッチ数が多い場合と少ない場合では所要時間の合計は変わるか? ⇒ バッチ数に応じて所要時間が増える
スクリプトはこちら
以下に各ベンチマークの結果を示します。
1. 1バッチ内のイベント数を変えた場合応答時間は変わるか?
user system total real 100 events 0.004398 0.000660 0.005058 ( 0.232147) 200 events 0.007362 0.000542 0.007904 ( 0.205907) 300 events 0.009468 0.000717 0.010185 ( 0.248149) 400 events 0.009571 0.000608 0.010179 ( 0.242053) 500 events 0.008937 0.000397 0.009334 ( 0.198640)
2. イベント数が同じ場合バッチ数が多い場合と少ない場合では所要時間の合計は変わるか?
user system total real events: 50, 100 times 0.305785 0.050613 0.356398 ( 23.339985) events: 500, 10 times 0.097342 0.003924 0.101266 ( 2.486756) events: 5000, 1 times 0.080290 0.004738 0.085028 ( 2.392611) # 2,3番目はバッチ数は同じ
おまけ: イベント数とバッチ数を両方変えるパターン
user system total real 500 with 1 batches 0.050094 0.005268 0.055362 ( 0.870537) 1000 with 2 batches 0.014764 0.001317 0.016081 ( 0.448666) 1500 with 3 batches 0.032424 0.001874 0.034298 ( 0.685703) 2000 with 4 batches 0.040220 0.002320 0.042540 ( 0.935449) 2500 with 5 batches 0.049319 0.002627 0.051946 ( 1.163777) 3000 with 6 batches 0.055695 0.003089 0.058784 ( 1.341832) 3500 with 7 batches 0.058091 0.003541 0.061632 ( 1.673359) 4000 with 8 batches 0.068821 0.003804 0.072625 ( 1.840564) 4500 with 9 batches 0.079897 0.005041 0.084938 ( 2.186967) 5000 with 10 batches 0.082409 0.005275 0.087684 ( 2.268407)
結論
以下のことがわかりました。
プラグインではチャンクサイズによらず、Datadog のAPIの仕様にあわせてイベントをバッチ化する、またフラッシュの所要時間はバッチ数に比例する。チャンクサイズとバッチ数は比例するので、フラッシュ所要時間とスループットはトレードオフである。
所要時間はバッチ数(=APIリクエストの数)に応じて増えるのでバッチ数を最小化するようにイベントを分割する現在の実装はスループットに最適化されている。